『塩野義製薬様のAWS統合管理戦略：Organizations設計と運用の具体例』というタイトルでClassmethod Showcaseに登壇しました

はじめに

お疲れさまです。とーちです。
2024/9/25に開催された「Classmethod Showcase ビジネス成長を支えるITガバナンス」というウェビナーで登壇しました。
本記事ではその際に使用した資料をご紹介します。

登壇資料

資料概要

資料は大きく「AWS Organizationsの設計」と「運用設計」の２つのテーマで分かれています。
「AWS Organizationsの設計」では塩野義製薬様でご支援させて頂いた内容を元に以下の内容について記載しています。

• OU設計
• SCP設計
• IAM Identity Center設計

また「運用設計」の項目ではAWS上でシステムを運用する場合にどのような作業項目があるかを一から検討した際の考え方について記載しています。

Q&Aのご紹介

セッションにてご質問頂いた内容とご回答についてご紹介します。

super-developerとdeveloperの許可セットで許可しているNW関連の権限とはどのようなものになりますでしょうか

ちょっとわかりにくい記載だったのでこういったご質問を頂いたのだと思います。
両許可セットでは、NW関連の操作が出来ないように 拒否 しています。例えばInternet Gateway等の作成を禁止することによって想定している経路以外でインターネットに出ることが出来ないようにしている形です。

旧・新Organizationsアカウントの統合において、上記のOUやアクターの差異があったかと存じますが、その際、何か不都合や困ったことなどはございましたでしょうか

旧Organizationsアカウントからの移行に際してはAWSアカウントごと移行するのではなくEC2等のリソース単位で移行していったので、OUやアクターの差異でそこまで困ったことはなかった認識です。これは基本的に社内向けのサービスという特性によるところも大きいと思っています。

Azure ADと連携してSSOなどを実装していると理解していますが、AD側とAWS Organizations側で、それぞれ組織・権限の構造・構成などがあるかと存じますが、互いに同じにするように意識はしましたでしょうか

IAM Identity Center側のグループは登壇資料の中でもお伝えしたようにAWSアカウントへの権限管理に特化した設計となっているので、AD側とは組織等の構成は異なります。そのため意図して同じになるようにはしていません。

感想

塩野義製薬様でのご支援経験をもとに資料を作成しましたが、振り返ってみると、弊社クラスメソッドのOrganizations関連の記事を参考にした部分が多くあり、改めて、弊社のOrganizationsに関する知識を持つメンバーの優れた専門性を実感する機会となりました。

この記事が誰かのお役に立てばなによりです。
以上、とーちでした。

参考にさせて頂いた記事・サイト

• Terminology and concepts for AWS Organizations - AWS Organizations
• AWSのマルチアカウント管理で意外と知られていないOU設計の話 - Speaker Deck
• Introduction: AWS Control Tower Controls Reference Guide - AWS Control Tower
• Permissions boundaries for IAM entities - AWS Identity and Access Management
• AWS SSO管理者がユーザーの作成するIAMロールの権限を制限する方法 | DevelopersIO
• マルチアカウント環境でセキュリティサービスの検出結果を全てSecurity Hubに集約して通知してみた | DevelopersIO
• Organizations 環境で Amazon GuardDuty を全リージョンへ簡単セットアップしてみる | DevelopersIO
• AWS Security Hub の検出結果を自動で「通知済み」にする | DevelopersIO